PageSpeed Insightsの指摘を元にCloudFrontの設定・利用状況を見直してみた

quiver

2020.05.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ウェブサイトのパフォーマンス改善のためにPageSpeed Insightsで分析している方は多いのではないかと思います。

本ブログでは、PageSpeed Insightsの改善項目のうち、Amazon CloudFrontを利用しているサイトに対してアクション可能な項目を4点紹介します。

1つは簡単な設定変更だけで済み、残り3つは遅い箇所にあたりをつけます。

端的には、ページサイズを小さくすることがゴールです。

サイズを小さくすることで、サービスを提供する側にとってはトラフィック量を軽減でき、利用する側にとってはページをより早く表示できるようになります。

事前準備

CloudFrontの利用状況を把握するためには、モニタリングやアクセスログがマストです。

まずはこれらを有効化します。

拡張モニタリングを有効化しよう

2019年12月に、以下のリアルタイムメトリックが追加されています。

キャッシュヒット率
オリジンのレイテンシー(TTFB)
ステータスコード別のエラー率(401,403, 404, 502, 503, 504)

有効化しましょう。

CloudFrontのアクセスログをS3にエクスポートしよう

トラブルシュートや利用状況を把握するためにCloudFrontのアクセスログが必要です。

出力しましょう。

ストレージコスト軽減のために、一定期間が経過したアクセスログを削除するようS3のライフサイクルを設定しましょう。

S3 バケットのライフサイクルポリシーを作成する方法 - Amazon Simple Storage Service

アクセスログをAmazon AthenaでSQL分析できるようにしよう

Amazon Athenaを利用すると、S3にエクスポートしたアクセスログをSQLで探索的に分析できます。

ログを有効活用するためにも、次のドキュメントに従いAthena用にテーブル定義しましょう。

Amazon CloudFront ログのクエリ - Amazon Athena

ログフォーマットは、2019年12月に拡張されています。

【新機能】Amazon CloudFrontのアクセスログに新フィールドが追加されました！

拡張前にテーブル定義した場合は、再定義しましょう。

パフォーマンス観点では

time-to-first-byte(TTFB)
sc-content-type(コンテントタイプ)

を、トラブルシュート観点では

x-edge-detailed-result-type(エラーの詳細タイプ)

を活用できるようになります。

PageSpeed Insightの提案をCloudFrontと付き合わせる

以下では、PageSpeed Insightの改善提案に対して、CloudFrontをどの設定したり、ログを調査すればよいのか解説します。

なお、CloudFrontとは直接関係のない提案は除外しています。

テキスト圧縮の有効化

指摘

テキストベースのリソースは圧縮（gzip、deflate、または brotli）して配信し、ネットワークの全体的な通信量を最小限に抑えてください。詳細

対応

CloudFront ディストリビューションがコンテンツを圧縮するように設定します。

テキストベースのリソースを配信する各ディストリビューションに対して、「Compress objects automatically」を有効にしてgzip圧縮します。

次世代フォーマットでの画像の配信

指摘

JPEG 2000、JPEG XR、WebP などの画像フォーマットは、PNG や JPEG より圧縮性能が高く、ダウンロード時間やデータ使用量を抑えることができます。詳細

対応

GIFやJPEGといった昔ながらの画像フォーマットで配信していることが考えられます。

配信している画像フォーマットをAthenaで確認します。

SELECT sc_content_type,
         count(*) cnt
FROM cloudfront_logs
WHERE strpos(sc_content_type, 'image/') > 0
        AND date = DATE '2020-05-01'
GROUP BY  sc_content_type
ORDER BY  cnt desc

以下のような次世代フォーマットで配信されていたでしょうか?

フォーマット	Content-Type
JPEG 2000	image/jp2 image/jpx
JPEG XR	image/vnd.ms-photo image/jxr
WebP	image/webp

次世代の画像配信の注意点としては、ブラウザごとに対応しているフォーマットが異なっており、元画像からのフォーマット変換も必要なことです。

自社開発・運用するには潤沢なリソースが必要ですが、画像最適化SaaSを利用すること、簡単に次世代フォーマットで画像配信できます。

興味のある方は、お気軽にご相談ください。

効率的な画像フォーマット

指摘

画像を最適化すると、読み込み時間を短縮しモバイルデータ量を抑えることができます。詳細

対応

「次世代フォーマットでの画像の配信」との違いが気になります。英語では「Efficiently encode images」となっており、オーバースペックな画質が問題視されています。

画像最適化SaaSを利用すると、ブラウザ・元画像にあわせて画質を最適化して配信できます。

興味のある方は、お気軽にご相談ください。

サーバー応答時間の短縮（TTFB）

指摘

最初の 1 バイトまでの時間は、サーバーが応答を返すまでにかかった時間を表しています。詳細

対応

この項目が指摘される場合、オリジンからのコンテンツ取得が遅いことを意味します。

リクエスト全体でならしたTTFBは CloudFront リアルタイムメトリクスのオリジンのレイテンシーで取得できているため、CloudFront アクセスログの28番目のフィールドの time-to-first-byte を利用してドリルダウンします。

CloudFrontのアクセスログに対してAthenaで問い合わせて、特に遅いリクエストを洗い出します。

次のSQLは、平均TTFBが1秒を超えるURIを抽出しています。

エッジ↔オリジン間の通信距離による遅延を排除するため、オリジンが東京リージョンにある前提で、日本のエッジサーバー(location=NRT*)からのアクセスに限定しています。

SELECT uri,
         avg(time_to_first_byte) ttfb,
         count(*) cnt
FROM cloudfront_logs
WHERE status = 200
        AND date = DATE '2020-05-01'
        AND strpos(location, 'NRT') > 0 -- 東京エッジからのアクセス
        AND result_type = 'Miss' -- オリジンにリクエスト
GROUP BY  uri
HAVING avg(time_to_first_byte) > 1.0
ORDER BY  ttfb desc

URI単位の代わりにBehavior単位にするなど、切り口をいろいろ変えてみてください。

遅いURIを特定したあとは